3D Graphics Programming with QuickDraw 3D 1.5.4

Using Trimeshes

Like the polyhedron, the trimesh uses a list of points and a list of triangular faces that contain indices into the list of points. It also has an optional edge list. However, it differs from the polyhedron in other ways. The trimesh primitive has several unique characteristics that significantly affect its applicability:

All trimesh data values are stored in explicit arrays--vertex locations, vertex attributes, triangle attributes, and edge attributes.
Trimeshes generally do not keep attributes in objects of type TQ3AttributeSet ; instead, their attributes are kept as arrays of explicit data structures. However, the trimesh does maintain a TQ3AttributeSet object for its whole geometry, like other primitives.
With the exception of custom attributes, every vertex, face, or edge of a trimesh must have exactly the same types of attributes. For example, you must put a color on every face of a trimesh if you want to put a color on just one face; similarly for vertices and edges. For some types of models, such as those in existing applications ported to QuickDraw 3D that already use uniform attributes, this may not be a problem. In such cases, the trimesh may be the natural choice, as well as being faster and more compact.

The uniform-attributes requirement just mentioned, and the use of arrays of explicit data for attributes, can make the trimesh format preferable to the polyhedron in some models and applications. However, these features make it hard to use trimeshes to represent arbitrary, nonuniform polyhedra. Many solid shapes have regions that are smoothly curved and regions that are flat or faceted, as well as sharp edges, corners, and creases. The vertices in the curved regions need normals that approximate the surface normal at that vertex, but vertices at corners or along edges or in flat regions need none. With the polyhedron, mesh, and trigrid formats, you must allocate storage for normals only for those vertices that actually require a normal. With the trimesh format, you must allocate vertex normals on all vertices, causing heavy memory usage.

This same problem applies to face attributes. Solid shapes often have regions that differ in color, transparency, or surface texture. For example, a soccer ball has black and white faces and a wine bottle may have a label on the front, a different label on the back, and another around the neck. The other polyhedral primitives would, in the case of the soccer ball, simply create two attribute sets (one for each color) and attach a reference to the appropriate attribute set to each face, thus sharing the color information. The trimesh format is forced to create an array of colors, using a lot of memory to represent the same data over and over. If you wanted to highlight one face of a soccer ball, you couldn't just attach a highlight switch attribute to that face, set to "on"--you'd need to attach it to the rest as well, set to "off." In the case of the wine bottle, you would want to attach label textures to the appropriate faces on the bottle by attaching texture parameters to the vertices of those faces. With a trimesh, this powerful approach is not possible.

When using the trimesh for large polyhedral models, these problems can result in heavy space usage, both on disk and in memory. Consider a 10,000-face model whose faces are either red or green. The other polyhedral primitives would use references to just two color attribute sets while the trimesh would need 10,000 * 12 = 120,000 bytes. If the red faces were to be transparent, a trimesh would use another 120,000 bytes. Highlighting just one face would require 40,000 bytes more, and the same sort of data explosion would happen with vertex attributes as well. These problems don't occur with the other polyhedral primitives.

In spite of these features that limit the suitability of the trimesh for general-purpose polyhedral representation, the uniform-attributes requirement makes it ideal for models in which each vertex or face naturally has the same type of attributes as the other vertices (or faces), but with different values. For example, if your application uses Coons patches, it could subdivide the patch into a trimesh with normals on each vertex. Games often are written with objects such as walls, or even some stylized characters, that typically have just one texture and either no vertex attributes or normals on every vertex. Multimedia, some demo programs, and other "display-only" applications in which the user is unable to modify objects may find the trimesh useful, at least for shapes that don't evoke the memory usage problems described above.

Geometric editing operations in immediate mode for the trimesh are similar to those for the polyhedron: you simply alter a point's position in the array in the trimesh data structure and render the shape again. There are no retained-mode API calls for editing parts of a trimesh. Topological editing in immediate mode is also similar to that for the polyhedron. Because there are no suitable API calls, however, it is impossible to edit a trimesh object topologically in retained mode.

The uniform-attributes requirement for trimeshes causes generally good I/O performance. However, poor I/O speeds may result from the repeated transfer of multiple copies of the same data (for example, the same color on every face). Rendering speed for the trimesh is usually good.